Chip 1998 September

home *** CD-ROM | disk | FTP | other *** search

/ Chip 1998 September / CHIP Eylül 1998.iso / Slackwar / docs / linux-2.0.34 / specialix.txt < prev next >

Wrap

Text File | 1997-08-11 | 13KB | 335 lines

specialix.txt -- specialix IO8+ multiport serial driver readme. Copyright (C) 1997 Roger Wolff (R.E.Wolff@BitWizard.nl) Specialix pays for the development and support of this driver. Please DO contact io8-linux@specialix.co.uk if you require support. This driver was developed in the BitWizard linux device driver service. If you require a linux device driver for your product, please contact devices@BitWizard.nl for a quote. This code is firmly based on the riscom/8 serial driver, written by Dmitry Gorodchanin. The specialix IO8+ card programming information was obtained from the CL-CD1865 Data Book, and Specialix document number 6200059: IO8+ Hardware Functional Specification. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. Intro ===== This file contains some random information, that I like to have online instead of in a manual that can get lost. Ever misplace your Linux kernel sources? And the manual of one of the boards in your computer? Adresses and interrupts ======================= Addres dip switch settings: The dip switch sets bits 2-9 of the IO address. 9 8 7 6 5 4 3 2 +-----------------+ 0 | X X X X X X X | | | = IoBase = 0x100 1 | X | +-----------------+ ------ RS232 connectors ----> | | | edge connector | | | V V V Base address 0x100 caused a conflict in one of my computers once. I haven't the foggiest why. My Specialix card is now at 0x180. My other computer runs just fine with the Specialix card at 0x100.... The card occupies 4 addresses, but actually only two are really used. The driver now still autoprobes at 0x100, 0x180, 0x250 and 0x260. If that causes trouble for you, please report that. I'll remove autoprobing then. The driver will tell the card what IRQ to use, so you don't have to change any jumpers to change the IRQ. Just use a command line argument (irq=xx) to the insmod program to set the interrupt. If your specialix cards are not at the default locations, you can use the kernel command line argument "specialix=io0,irq0,io1,irq1...". Here "io0" is the io address for the first card, and "irq0" is the irq line that the first card should use. And so on. Examples. You use the driver as a module and have three cards at 0x100, 0x250 and 0x180. And some way or another you want them detected in that order. Moreover irq 12 is taken (e.g. by your PS/2 mouse). insmod specialix.o iobase=0x100,0x250,0x180 irq=9,11,15 The same three cards, but now in the kernel would require you to add specialix=0x100,9,0x250,11,0x180,15 to the command line. This would become append="specialix=0x100,9,0x250,11,0x180,15" in your /etc/lilo.conf file if you use lilo. Baud rates ========== The rev 1.2 and below boards use a CL-CD1864. These chips can only do 64kbit. The rev 1.3 and newer boards use a CL-CD1865. These chips are officially capable of 115k2. The Specialix card uses a 25MHz crystal (in times two mode, which in fact is a divided by two mode). This is not enough to reach the rated 115k2 on all ports at the same time. With this clock rate you can only do 37% of this rate. This means that at 115k2 on all ports you are going to loose characters (The chip cannot handle that many incoming bits at this clock rate.) (Yes, you read that correctly: there is a limit to the number of -=bits=- per second that the chip can handle.) If you near the "limit" you will first start to see a graceful degradation in that the chip cannot keep the transmitter busy at all times. However with a central clock this slow, you can also get it to miss incoming characters. The specialix card cannot reliably do 115k2. If you use it, you have to do "extensive testing" (*) to verify if it actually works. When "mgetty" communicates with my modem at 115k2 it reports: got: +++[0d]ATQ0V1H0[0d][0d][8a]O[cb][0d][8a] ^^^^ ^^^^ ^^^^ The three characters that have the "^^^" under them have suffered a bit error in the highest bit. In conclusion: I've tested it, and found that it simply DOESN"T work for me. I also suspect that this is also caused by the baud rate being just a little bit out of tune. (*) Cirrus logic CD1864 databook, page 40. Cables for the Specialix IO8+ ============================= The pinout of the connectors on the IO8+ is: pin short direction long name name Pin 1 DCD input Data Carrier Detect Pin 2 RXD input Receive Pin 3 DTR/RTS output Data Terminal Ready/Ready To Send Pin 4 GND - Ground Pin 5 TXD output Transmit Pin 6 CTS input Clear To Send -- 6 5 4 3 2 1 -- | | | | | | | | +----- -----+ |__________| clip Front view of an RJ12 connector. Cable moves "into" the paper. (the plug is ready to plug into your mouth this way...) NULL cable. I don't know who is going to use these except for testing purposes, but I tested the cards with this cable. (It took quite a while to figure out, so I'm not going to delete it. So there! :-) This end goes This end needs straight into the some twists in RJ12 plug. the wiring. IO8+ RJ12 IO8+ RJ12 1 DCD white - - - 1 DCD 2 RXD black 5 TXD 3 DTR/RTS red 6 CTS 4 GND green 4 GND 5 TXD yellow 2 RXD 6 CTS blue 3 DTR/RTS Same NULL cable, but now sorted on the second column. 1 DCD white - - - 1 DCD 5 TXD yellow 2 RXD 6 CTS blue 3 DTR/RTS 4 GND green 4 GND 2 RXD black 5 TXD 3 DTR/RTS red 6 CTS This is a modem cable usable for hardware handshaking: RJ12 DB25 DB9 1 DCD white 8 DCD 1 DCD 2 RXD black 3 RXD 2 RXD 3 DTR/RTS red 4 RTS 7 RTS 4 GND green 7 GND 5 GND 5 TXD yellow 2 TXD 3 TXD 6 CTS blue 5 CTS 8 CTS +---- 6 DSR 6 DSR +---- 20 DTR 4 DTR This is a modem cable usable for software handshaking: It allows you to reset the modem using the DTR ioctls. I (REW) have never tested this, "but xxxxxxxxxxxxx says that it works." If you test this, please tell me and I'll fill in your name on the xxx's. RJ12 DB25 DB9 1 DCD white 8 DCD 1 DCD 2 RXD black 3 RXD 2 RXD 3 DTR/RTS red 20 DTR 4 DTR 4 GND green 7 GND 5 GND 5 TXD yellow 2 TXD 3 TXD 6 CTS blue 5 CTS 8 CTS +---- 6 DSR 6 DSR +---- 4 RTS 7 RTS I bought a 6 wire flat cable. It was colored as indicated. Check that yours is the same before you trust me on this. Hardware handshaking issues. ============================ The driver can be compiled in two different ways. The default ("Specialix DTR/RTS pin is RTS" is off) the pin behaves as DTR when hardware handshaking is off. It behaves as the RTS hardware handshaking signal when hardware handshaking is selected. When you use this, you have to use the appropriate cable. The cable will either be compatible with hardware handshaking or with software handshaking. So switching on the fly is not really an option. I actually prefer to use the "Specialix DTR/RTS pin is RTS" option. This makes the DTR/RTS pin always an RTS pin, and ioctls to change DTR are always ignored. I have a cable that is configured for this. Ports and devices ================= Port 0 is the one furthest from the ISA connector. Devices: You should make the devices as follows: bash cd /dev for i in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 \ 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 do echo -n "$i " mknod /dev/ttyW$i c 75 $i mknod /dev/cuw$i c 76 $i done echo "" You cannot have more than 4 boards in one computer. The card only supports 4 different interrupts. If you really want this, contact me about this and I'll give you a few tips (requires soldering iron).... ------------------------------------------------------------------------ Fixed bugs and restrictions: - During intialization, interrupts are blindly turned on. Having a shadow variable would cause an extra memory access on every IO instruction. - The interrupt (on the card) should be disabled when we don't allocate the Linux end of the interrupt. This allows a different driver/card to use it while all ports are not in use..... (a la standard serial port) == An extra _off variant of the sx_in and sx_out macros are now available. They don't set the interrupt enable bit. These are used during initialization. Normal operation uses the old variant which enables the interrupt line. - RTS/DTR issue needs to be implemented according to specialix' spec. I kind of like the "determinism" of the current implementation. Compile time flag? == Ok. Compile time flag! Default is how Specialix likes it. == Now a config time flag! Gets saved in your config file. Neat! - Can you set the IO address from the lilo command line? If you need this, bug me about it, I'll make it. == Hah! No bugging needed. Fixed! :-) - Cirrus logic hasn't gotten back to me yet why the CD1865 can and the CD1864 can't do 115k2. I suspect that this is because the CD1864 is not rated for 33MHz operation. Therefore the CD1864 versions of the card can't do 115k2 on all ports just like the CD1865 versions. The driver does not block 115k2 on CD1864 cards. == I called the Cirrus Logic representative here in Holland. The CD1864 databook is identical to the CD1865 databook, except for an extra warning at the end. Similar Bit errors have been observed in testing at 115k2 on both an 1865 and a 1864 chip. I see no reason why I would prohibit 115k2 on 1864 chips and not do it on 1865 chips. Actually there is reason to prohibit it on BOTH chips. I print a warning. If you use 115k2, you're on your own. - A spiky CD may send spurious HUPs. Also in CLOCAL??? -- A fix for this turned out to be counter productive. Different fix? Current behaviour is acceptable? -- Maybe the current implementation is correct. If anybody gets bitten by this, please report, and it will get fixed. -- Testing revealed that when in CLOCAL, the problem doesn't occur. As warned for in the CD1865 manual, the chip may send modem intr's on a spike. We could filter those out, but that would be a cludge anyway (You'd still risk getting a spurious HUP when two spikes occur.)..... Bugs & restrictions: - This is a difficult card to autoprobe. You have to WRITE to the address register to even read-probe a CD186x register. Disable autodetection? -- Specialix: any suggestions? - Arbitrary baud rates are not implemented yet. If you need this, bug me about it.